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Taller Virtual Nuevas sentencias de programación (III) 
Cómo... El futuro de la animación con POV 
En el CD Las mejores escenas de la Internet Raytracing Competition 
El foro del lector Animaciones de gran tamaño 


uevamente quere- 


mos insistir en la 


particular. Con estas dos nuevas sentencias, importancia de las 
llamadas sentencias 

el lenguaje escénico de POV pasa a ser un de programación. 
Las sentencias con- 

verdadero lenguaje de programación con el vencionales de construcción de obje- 
tos de «POV» nos permitirán crear 

que podremos hacer cosas que antes sólo modelos de gran complejidad, pero es- 


tas sentencias por sí solas no nos pro- 
eran posibles con la utilización de utilidades porcionarán ninguna ventaja con res- 
pecto a los modeladores visuales 
externas. (basados en la edición con ventanas de 
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trabajo). Es más, con «POV» es muy 
difícil -si no imposible- crear ciertos 
modelos como los que pueden ser 
construidos con modeladores como 
«Rhino», «Spatch», «MAX» y cual- 
quier otro programa que utilice splines. 
Por esta razón, muchos usuarios de 
»POV» exportan a dicho programa 
modelos construidos desde otros pro- 
gramas y utilizan el lenguaje escénico 
de este raytracer para construir la esce- 
na situando los objetos, las luces y la 
cámara. Obrando así no sólo podremos 
aprovecharnos de la magnífica calidad 
del render de «POV», sino también de 
las posibilidades que ofrecen sus sen- 
tencias de “programación”. Utilizando 
estas sentencias podremos manipular 
los modelos y generar escenas impre- 
sionantes cuya creación resultaría pro- 
blemática o imposible desde un mode- 
lador visual. (Nota: Quizá «MAX» sea 
una excepción a esto. Parece que este 
programa dispone de un lenguaje pro- 
pio muy potente y quizá con él podrían 
crearse escenas comparables a las del 
número 17 de Rendermanía). 


HDeclare y HLocal 

En el número 17 de Rendermanía 
aprendimos a utilizar la sentencia HHde- 
clare para definir objetos que más tarde 
podían ser referenciados y empleados 
cuantas veces fuese necesario. Vimos. 
además. cómo tideclare podía ser utili- 
zada para crear variables o cambiar el 
valor de éstas, siendo esto la base de to- 
da la parte de “programación” que tie- 
ne el lenguaje escénico de «POV» 
(puesto que estas variables se emplean 
más tarde para estudiar las condiciones 
de sentencias como Hifo Htswitch, o pa- 
ra tratar los contadores de *twhile). A 
continuación vamos a presentar una 


Dos experimentos para el Ipas 
de explosiones de Colefax. 


nueva sentencia incluida en la nueva 
versión 3.1 de «POV». Se trata de HHlo- 
cal, cuyo uso y funcionamiento es 
prácticamente idéntico al de tdeclare. 
Por ejemplo, utilizando +kdeclare... 


ttdeclare xa=5:; 
tideclare xa=xa+ 1; 


la primera sentencia asignará a la va- 
riable xa el valor 5 y la segunda dejará 
a xa con el valor 6. Pues bien, las dos 
siguientes líneas harán exactamente lo 
mismo utilizando *local: 


HHocal xa=5; 
iélocal xa=xa+ 1; 


Puesto que tHocal también se emplea 
de la misma forma que +declare. es de- 
cir, para asignar un objeto a un identifi- 
cador, el lector estará empezando a pre- 


guntarse para qué se ha incluido a esta 
sentencia en el lenguaje de «POV”. La 
respuesta está en que emplearemos 
flocal para utilizar variables locales y 
tideclare para emplear variables globa- 
les. (Sin duda, con esta última frase los 
aficionados a la programación creerán 
tenerlo todo claro, pero el caso es que 
las variables locales de «POV» funcio- 
nan de una manera algo diferente a co- 
mo lo hacen las de C, de manera que 
será mejor que no os saltéis las expli- 
caciones siguientes). Aquí, como en el 
lenguaje C, las palabras global y local 
se refieren al ámbito en el cual la va- 
riable será reconocida (por el compila- 
dor) y podrá ser utilizada. Las variables 
globales. una vez creadas. pueden ser 
referenciadas y empleadas a lo largo de 
cualquier parte del programa. Las va- 
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niables locales, en cambio, solamente 


son conocidas dentro del bloque en el 
cual han sido definidas. Si se intenta re- 
ferenciar a una variable local desde fue- 
ra del bloque en el que ha sido creada, 
entonces el programa dará un error in- 
dicando que esa variable no existe. Esto 
no incluye el caso de los bloques de có- 
digo inscritos dentro del bloque donde 


se ha definido la variable local. como : 


sucede en el caso de las macros (las 
cuales serán explicadas más adelante). 
A continuación intentaremos expli- 


car las reglas de alcance o ámbito por E 


las que se rigen las variables locales. 
Para empezar, ¿a qué nos referimos con 
la palabra bloque? Bien, en el lenguaje 
C (con el que «POV» cada vez tiene 
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más semejanzas) un bloque es cual- 
quier extensión de código delimitada 
por llaves. En C un bloque puede ser el 
código inscrito dentro de las llaves de 
una función o el delimitado por las lla- 
ves de un if. Esto significa que, como 
podemos escribir sentencias if dentro 
de las funciones, puede haber bloques 
dentro de bloques. Supongamos que 
creamos una variable local dentro de 
un bloque C que está incluido dentro 
de un bloque B que se encuentra, a su 
vez, incluido dentro de un bloque A. 
Pues bien, la variable local definida 
dentro de C sólo será conocida por este 
bloque y no por B ni por A. (Se dice 
entonces que la variable es local al blo- 
que C). Ahora supongamos que defini- 


mos a esta variable local dentro del 
bloque B en lugar de hacerlo en el €. 
En este caso la variable no será conoci- 


: da por A pero sí por B y por C. ¿Por 


qué por C? Pues porque el bloque C es- 
tá incluido dentro del bloque B y forma 
parte del mismo. Diciéndolo de otra 
manera: el bloque C se encuentra den- 
tro del ámbito o alcance del bloque B. 
Esto significa que cualquier variable 
local de B es una variable local de € 
mientras que lo contrario no es cierto. 
Estas mismas reglas de funciona- 
miento de ámbitos, tan bien conocidas 


: por los programadores de C, se aplican 


del mismo modo a las variables loca- 
les de «POV» cuando trabajamos con 
macros, como veremos después. Pero 
lo dicho no rige cuando se están utili- 
zando ficheros incluidos. Supongamos 
que tenemos un archivo C que es leído 
(con HHinclude) por un fichero B que a 
su vez es leído por un fichero A. En es- 
te caso una variable local definida en 


3 el fichero B no sería reconocida dentro 


del fichero C ni dentro del A. En otras 
palabras, un fichero leído por otro no 
se considera como parte del bloque que 
forma el fichero lector. 

Al llegar aquí es probable que los 
lectores no amantes de la programa- 
ción se sientan algo liados. Enseguida 
pondremos algunos ejemplos pero an- 
tes reseñaremos dos puntos importan- 


tes. El primero es que, como recorda- 


réis, en «POV» los bloques de código 
no se delimitan con llaves sino. como 
hemos visto en los casos de +t1f, +twhile 


: y switch, con la sentencia Hend (que 


cierra el bloque de código abierto con 
la sentencia +f, while o switch que 
hayamos usado). El segundo punto, 
mucho más importante, estriba en que 


las variables locales de «POV>» no son 
locales a estos bloques de código, sino 
a ficheros y a macros. 

¿Cómo? ¿Que aún no habéis enten- 
dido nada? Vale, vamos a poner un 
ejemplo práctico. Supongamos que te- 
nemos un fichero llamado batalla.pov 
con el que pretendemos generar una es- 
cena donde se ilustra una de nuestras 
típicas batallas entre orcos y humanos. 
A este archivo podemos llamarlo el fi- 
chero principal del proyecto o princi- 
pal a secas. Contendrá las definiciones 
de la cámara y las de las luces, y proba- 
blemente también una serie de bucles 
ttwhile para situar las formaciones de 
contendientes en el pov-espacio. Como 
sabéis, por criterios de claridad y fun- 
cionalidad, es raro que un proyecto lo 
suficientemente complejo (como lo se- 
ría el del ejemplo) conste de un único 
fichero. En este ejemplo supondremos 
que batalla.pov tendrá en su código un 
par de sentencias +finclude para cargar 
a los archivos humano.inc y orco.inc. 
Si la escena muestra a dos ejércitos 
puestos frente a frente, parte del código 
de batalla.pov podría consistir en dos 
bloques bien diferenciados, constando 
cada uno de ellos de un doble bucle 
ftwhile para crear una formación rec- 
tangular de guerreros. Dentro del cen- 
tro de cada uno de estos bloques habría 
una sentencia +tinclude de manera que. 
con cada pasada del bucle, se invocase 
a humano.inc o a orco.inc (dependien- 
do del bloque) para crear un modelo. 
Por supuesto, la función de humano.inc 
sería la de crear un humano en la posi- 
ción espacial indicada por las variables 
del bucle y orco.inc realizaría la mis- 
ma tarea para los orcos. Pues bien, ima- 
ginad que escribimos la siguiente línea 
en algún lugar dentro de batalla.pov, 


Otro pov-ipas 
para crear 
extraños efectos 
explosivos. 


antes de las líneas include a huma- 
no.inc y orco.inc: 


tidectare godel=25: 


Como ha sido definida utilizando 
fidectare, godel es una variable global y 
podrá ser invocada y alterada dentro de 
humano.inc y orco.inc. En caso de que 
la misma línea hubiese sido escrita 
dentro de, por ejemplo, humano.inc y 
no en batalla.pov, entonces la variable 
godel también seguiría siendo global 
(al haber sido definida con declare) y 
desde 
batalla.pov, en cualquier línea posterior 


podría ser  referenciada 
a la sentencia *tinclude “humano.inc”. 
En definitiva. una variable global pue- 
de ser referenciada y tratada desde 
cualquier fichero de un proyecto, una 
vez que ha sido definida. 

Ahora supongamos que escribimos 
dentro de 


la siguiente línea 


humano. inc: 
ttlocal escher=26; 


Esto declara a escher como una va- 
riable loca! al fichero humano.inc. Esto 
quiere decir que esta variable podrá ser 
tratada desde cualquier punto de huma- 
no.inc (posterior al de su declaración, 
claro está) pero no deberemos invocar- 
la desde batalla.pov, so pena de error 
de compilación. En otras palabras, es- 
cher se convertirá en una variable local 
a humano.inc y, si escribiésemos en ba- 


talla.pov u orco.inc una línea como 
“focal escher=escher+1;” o como 
“Fdeclare escher=escher+1;”, entonces 
«POV» nos daría un mensaje de error. 
(Nota: recordad que cuando «POV» 
halla una nueva variable, la declaración 
no debe ser algo como “Hdeclare varia- 
ble=variable+1;”, pues entonces 
«POV» interpretará que la asignación 
del valor depende de una variable a la 
que aún no se ha asignado valor algu- 
no, es decir, que no existe). 

Ahora veamos otro caso. Suponga- 
mos que humano.inc tiene, a su vez, en 
alguna parte de su código una sentencia 
ttinclude que carga el fichero human- 
da.inc y que dentro de este último fi- 
chero existe la siguiente línea: 


flocal bach=27; 


Pues bien, bach solo podrá ser utiliza- 
da desde humanda.inc y no será conoci- 
da por humano.inc ni por batalla.pov. 


Nota importante 
sobre el punto y coma 

Antes de seguir haremos un inciso 
para comentar que el símbolo del punto 
y coma con el que estamos finalizando 
todas las líneas de asignación de varia- 
bles es una nueva adición a la sintaxis 
de «POV». En efecto. desde ahora. a 
partir de «POV 3.1», las sentencias de 
asignación a variables que asignen va- 
lores en flotante, vectores o colores de- 
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es, 


berán estar finalizadas por el símbolo 
del punto y coma, tal y como sucede 
con las sentencias de C. (Las dectara- 
ciones de objetos y texturas y las de- 
más sentencias no acabarán en punto y 
coma). Si no ponemos este símbolo, 
«POV» comenzará a imprimir mensa- 
jes de warning (atención). Con todo, 
puede suceder que el fichero se compi- 
le y la escena se genere. Pero es muy 
probable que haya problemas. sobre to- 
do si hay macros de por medio. Sólo 
por esta razón es muy probable que los 
escritores de pov-1pas deban adaptar su 
trabajo a la nueva versión. 


FMacro: 
¿Funciones de verdad? 

Si tenemos que escribir repetida- 
mente un mismo trozo de código a lo 
largo de nuestro programa (o fuente, o 
fichero escénico), la tarea se nos hará 
tediosa y el propio texto del programa 
puede acabar haciéndose insufrible- 
mente largo y fastidioso de leer. Sin 
embargo. ahora. a partir de la versión 
3.1, podremos crear macros para aho- 
rrar tiempo y conseguir programas más 
compactos y de más fácil lectura. Una 
macro es un conjunto de sentencias que 
se asignan a un nombre al que llama- 
mos nombre de la macro. Una vez que 
una macro ha sido declarada, bastará 
con escribir su nombre en cualquier 
punto del programa para que «POV» 
inserte su código automáticamente en 


Figura 1: Sintaxis de declaración de una macro 


Hmacro nombre_macro(parametro |, parametro 2, parametro n) 


sentencias 


Send 
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Figura 2: Ejemplo de macro tomado de macrol.pov 


1/ Definición de la macro Make_Many. Los tres parámetros que usa son... 


11. Stuff: objeto que será copiado y rotado 
11 How_Many: Número de copias a hacer 
1 Axis: 


Himacro Make_Many (Stuff, How_Many. Axis) 


El eje alrededor del cual han de rotar las copias 


local Count=0: // Este identificador es local y temporal a esta macro 


Hwhile (Count<How_Many) 


object[ Stuff rotate Axis*Count*(360/How_Many)] 


ttlocal Count=Count+ 1: 
Htend 


ttend — /laquí se acaba la definición de la macro 


Hideclare Thing = cyfinder(0.x.0.1] //objeto cilíndrico 


HHaquí tenemos un ejemplo de uso de la macro 


object[ Make_Many (Thing.6.z) // Hace 6 objetos Thing y los rota alrededor del eje Z 


pigment[Blue] 


dicho punto, al compilar. A esto se le 
llama “expansión de ta macro”. Las 
macros tuvieron bastante importancia 
en la programación del ya vetusto len- 
guaje ensamblador pero en los lengua- 
jes más modernos, donde existen cosas 
como funciones y objetos (que no tie- 
nen nada que ver con los objetus de 
«POV»), las macros apenas se usan. 
Por supuesto, las macros convencio- 
nales no son demasiado flexibles pero 
afortunadamente las macros de «POV» 
no funcionan exactamente como tas ya 
conocidas por los programadores. Las 
macros de «POV» tienen caracterís- 
ticas que están a caballo entre las de las 
típicas macros y las de las funciones de 
C. El proceso de expan- 
sión de una macro de 
«POV» se realiza de ma- 
nera idéntica al de una 
macro convencional pero 
los parámetros no funcio- 
nan igual. Echad un vis- 
tazo a la sintaxis de de- 


claración de una macro. en la Figura 1. 
En esta estructura podemos distinguir 
tres partes. Por un lado está la cabecera 
de la macro, compuesta por la senten- 
cia Htmacro, el nombre de ta macro y 
los parámetros separados por comas. 
Luego está el llamado cuerpo de la ma- 
cro, compuesto por sentencias del len- 


Este pov-ipas de Joachin Puerschell es und 
de los muchos que existen para crear árbc 


Esta escena, obra de 
Nathan Kopp, utiliza 
los flares programad 
por el propio aytor. 


guaje escénico de «POV». Y finalmen- 
te tenemos la sentencia Htend que marca 
el final de la macro. La macro puede 
utilizar parámetros o no, pero aunque 
no los tenga los paréntesis deberán es- 
cribirse. En cuanto al cuerpo de la ma- 
cro, podemos emplear cualquiera de las 
sentencias de «POV». La única limita- 
ción está en que si utilizamos HHif o 
ttwhile, estas sentencias deberán estar 
completamente dentro (ftend incluido) 
o completamente fuera de ta macro. 
Las macros tienen alcance global y 
si se emplea un mismo nombre para 
una nueva macro, la definición de la 


anterior se pierde. Las macros se em- 
plean, simplemente escribiendo el 
nombre de las mismas en el lugar don- 
de queremos que se inserte su código. 
Además del nombre debemos invocar a 
la macro escribiendo entre sus parénte- 
sis tantos parámetros como se hayan 
empleado en la definición. Estos pará- 
metros pueden ser valores en flotante. 
vectores, nombres de pigmentos, de 
texturas, de objetos, etc., y serán em- 
pleados por el código expandido por la 
macro. Echad un vistazo a la macro de- 
clarada e invocada en la Figura 2. 
Como podéis ver, la declaración de 
la macro utiliza tres parámetros: Stuff. 
How_Many y Axis. Fijaos también en 
la invocación a la macro. En ella se in- 
dican tres elementos que serán pasados 
alos parámetros. El primero, Thing, es 
un objeto de «POV» que hemos creado 
en una línea anterior, la segunda es un 
valor numérico y la tercera indica un 
eje para la rotación. Al encontrar esta 
invocación, «POV expande la macro y 
crea una tabla local de símbolos donde 
asigna los parámetros escritos en la in- 
vocación a variables locales que tienen 
el mismo nombre que hemos dado a di- 
chos parámetros en la definición de la 
macro. Es en este punto donde las ma- 
cros de «POV» se diferencian de las 


convencionales. Al expandirse una ma- 
cro, durante la compilación, se crea 
siempre una tabla de símbolos locales 
con los parámetros. Esto, a todos los 
efectos. es lo mismo que si hubiéramos 
escrito las líneas siguientes al principio 
del cuerpo de la macro: 


local Thing = cylinder(0.x.0.1] 
local How_Many=6; 
ttlocal Axis=z 


Si os fijáis, en el código de la macro 
os daréis cuenta del cometido de la 
misma. Como parámetros hemos dado 
a Make_Many un objeto —un cilindro- 
que es asignado al identificador Stuff, 
el cual es empleado dentro de la sen- 
tencia object de la macro para crear las 
copias. El número de éstas, indicado en 
el parámetro How_Many, es utilizado 
como fímite por el contador del while. 
con lo cual se crean seis copias. Y cada 
copia es rotada en torno al eje Axis 
(que vale z) un número de grados que 
depende del número de copias. 

Finalmente, cuando «POV» halla el 
ftend que corresponde a la macro, 
las variables locales de la macro, entre 
las que se incluyen las creadas auto- 
máticamente con los nombres de 
los parámetros, se destruyen. Es decir, 
cuando se sale del código de ta macro, 
la fínea que sigue a la de su invoca- 
ción no sabe nada de las variables 
Stuff, How_Many o Axis, éstas no 
existen ya para el programa. Más tar- 
de, si 
la macro vuelve a ser invocada, la 
tabla de símbolos se creará de nuevo y 
estas variables volverán a existir, aun- 
que esta vez sus valores será proba- 
blemente distintos, dependiendo 
de lo que hayamos escrito para los 
parámetros. Es importante recordar un 


ns 


par de cosas: 


1) Al invocar a la macro hay que uti- 
lizar todos los parámetros que se han 
indicado en la declaración. De lo con- 
trario habrá error. 

2) Al emplear lus parámetros. hay 
que asegurarse de que los tipos de da- 
tos pasados a los parámetros corres- 
ponden con los tipos definidos en la 
dectaración. Cuando «POV» estudie 
la declaración de Make_Many, duran- 
te la compilación, comprobará que el 
identificador Stuff se utiliza como 
nombre de un objeto y por ello debe- 
remos pasar un nombre de objeto a 
Stuff. Si, en lugar de esto le pasamos 
un número o cualquier otra cosa, 
«POV» nos dará un error. 

Otro detalle importante es que cuan- 
do la macro crea un objeto (como en el 
ejemplo), este objeto no es local a la 
macro (con lo cual se destruiría al salir 
de la misma), sino que es devuelto por 
la macro de manera que puede ser asig- 
nado a un identificador y utilizado glo- 
balmente en el resto del programa. Por 
ejemplo, podríamos haber invocado a 


tideclare mio=object[ Make_Many (Thing.6,z)) 


la macro del ejemplo de este modo: 
Esto crea el objeto mío. 


Macros, variables locales y 
objetos y valores devueltos 
Hemos visto cómo una macro pue- 
de ser empleada para devolver un obje- 
to al programa. Pero la macro puede 
devolver también otras cosas. Si, por 
ejemplo, vamos a devolver un valor re- 
sultante de un cálculo, no necesitamos 
emplear *ocal ni H+declare. En la Figu- 
ra 3 tenemos un ejemplo muy sencillo 
de esto tomado del fichero exper!.pov 
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Figura 3: Una macro que devuelve un valor. 


*tmacro duplica(kuk) 
kuk*2 
ttend 


sphere(<0,0,0> duplica(2) pigment(Red] | 


(incluido en el CD-ROM). 

En este caso la macro duplica de- 
vuelve un valor que es empleado por la 
sentencia sphere como radio para la es- 
fera. (Damos el valor 2 como paráme- 
tro y se nos devuelve el valor 4). 

En fin, ahora que sabemos lo que es 
una macro podemos concluir la expli- 
cación anterior sobre el funcionamien- 
to de variables locales. Supongamos 
que tenemos un proyecto formado por 
un fichero principal (.pov) que incluye 
a un fichero secundario (.inc) dentro 
del cual hay definida una macro. Re- 
cordad que «POV» considera que las 
variables focales lo son a las macros y a 
los ficheros, por tanto, en el presente 
ejemplo, «POV» entiende que hay tres 
ámbitos, el del fichero principal, el del 
secundario y el de la macro. En el caso 
de los ficheros. una variable local defi- 
nida dentro de uno no puede ser cono- 
cida en otro archivo, pero el caso de las 
macros es distinto porque «POV» asu- 
me que el ámbito de la macro está in- 
cluido dentro del bloque del fichero del 
que forma parte. Bien, siguiendo con 
el ejemplo, en este proyecto hay defi- 
nida una variable local llamada Turing 
en el fichero .inc, antes de la invoca- 
ción a la macro, y hay otra variable lo- 
cal llamada Shannon definida dentro 
de la macro. Pues bien, la variable Tu- 
ring podrá ser utilizada por la macro 
porque «POV» entiende que esta for- 
ma parte del bloque del fichero .inc. En 


Colefax es quizás el más prolífico 
v-ipas. Aquí tenemos 


escritor de 


cambio, Shannon no será conocida por 
el fichero .inc porque es una variable 
local solamente a la macro. Como se 
ha explicado antes, Shannon será crea- 
da cuando la macro sea invocada (junto 
a otras variables para los parámetros, si 
los hay) y destruida cuando «POV» lle- 
gue al Htend que cierra la macro. En 
cuanto al fichero principal, no podrá 
referenciar a Turing ni a Shannon. 
Ahora vamos a considerar un par de 
casos de “choque” de variables. Se dice 
que hay choque de variables cuando 
utilizamos un mismo nombre para de- 
finir variables diferentes. Esto puede 
ocurrir en ciertos casos y no dará un 
error de sintaxis, aunque sí podemos 
cometer un error lógico si nos confun- 
dimos con la variable que estamos em- 
pleando. Suponed que hemos creado 
no una, sino tres variables llamadas Tu- 
ring. La primera la definimos con ttde- 
clare en el fichero principal dándole el 
valor 123, la segunda la definimos con 
Hlocal en el fichero secundario otor- 
gándole el valor 456, y la tercera la de- 
claramos como local dentro de la ma- 
cro asignándole el valor 789. Es 


el 


a 


importante comprender que aquí no 
hay una, sino tres variables distintas 
que emplean el mismo nombre. 
«POV» ha reservado memoria para las 
tres y nuestro Único problema será sa- 
ber a cuál estamos referenciando en ca- 
da momento. Si escribimos la siguiente 
sentencia dentro de la macro (y des- 


HHocal Turing=Turing+1; 


pués de definir la Turing local): 

¿Cuál de las tres variables estare- 
mos empleando? Pues la de la macro, 
y esta pasará a valer 790. (Como re- 
gla para no perderos, debéis pensar 
que «POV» siempre emplea la varia- 
ble local definida más recientemente, 
tal y como sucede en el lenguaje C). 
Después, al hallar el Hend, «POV» 
destruirá la tabla de variables locales 
de la macro y la variable Turing de la 
macro será borrada de la memoria. 
Entonces estaremos nuevamente den- 
tro del ámbito del fichero secundario 


ttlocal Turing=Turing+H; 


José Francisco García es uno de los pocos 
lectores que se ha animado a crear sus 
proplos pov-ipas. 


Hmacro alarga Y (mio,b) 

*ideclare mio=object (mio scale<1.b,1>] 
Hidectare b=b*2; 

tend 


itiocal mio=sphere[<0,0,0>.2 pigrment[Red]) 
télocal b=2; 

alarga Y (mio,b) 

object( mio) 


object[ mio translate<7.0,U> pigment(Blue] scale<1,b,I>] 


plane( y.0 pigment(White] | 


y si volvemos a escribir: 

estaremos alterando la variable local 
del fichero secundario. que quedará 
con el valor 457. Por último, cuando 
«POV>» regrese al fichero principal 
(después de compilar todas tas líneas 
del fichero secundario incluido), la ta- 
bla de variables locales del archivo se- 
cundario serán borradas. Únicamente, 
en adelante las nuevas modificaciones 
hechas a Turing se aplicarán sobre la 
variable global de este nombre. 

Ahora volvamos al asunto de la de- 
volución de valores por parte de las 
macros. Ya hemos visto cómo podemos 
hacer que una macro devuelva un va- 
lor. Hacer que modifique más valores 
tampoco es demasiado difícil. Simple- 
mente bastará con escribir sentencias 
tideclare para cambiar variables globa- 
les. Pero, ¿y si lo que deseamos es efec- 
tuar cambios en variables locales del fi- 
chero donde se ha expandido la macro? 


Figura 4: Una macro que devuelve 2 valores en variables locales. 


En ese caso lo que debemos hacer es lo 
que podéis ver en la Figura 4, donde 
hemos incluido el fichero de prueba ex- 
per2.inc, el cual es cargado por el fi- 
chero principal exper2.pov (ambos se 
encuentran incluidos en el CD). 

Como podéis, ver 
la macro alarga Y 
acepta dos identifi- 
cadores como pa- 
rámetros; el identi- 
ficador mio es un 
objeto, una esfera 
con dos unidades 
de radio y color ro- 
Jo, y el identifica- 
dor b es una varia- 
ble que se utiliza 
para escalar en el 
eje Y al objeto pa- 
sado como pará- 
metro. El resultado de este ejemplo es 
que se crea una esfera roja de radio 2 
cuya longitud se multiptica por el valor 
de b (es decir, que se estira a lo largo 
de Y). Además, como el valor de b se 
devuelve multiplicado por 2, la si- 
guiente esfera (de color azul) puede uti- 
hizar dicho valor para estirarse aun más. 
Observad que para devolver los cam- 
bios hechos en la macro a las variables 
locales, éstas han de modificarse utili- 
zando *declare y no *ttocal. Además, 
para que esto funcione son necesarias 
dos cosas. Primero que las variables se 
hayan creado como locales antes de in- 
vocar a la macro y, segundo, que utilice- 
mos los identificadores de las variables 
locales como parámetros para la macro. 
Si empleamos valores constantes u Ob- 
jetos o cualquier otra cosa como pará- 
metros (en vez de identificadores), las 
variables locales correspondientes no 
podrán ser alteradas por la macro. Si, 


Htlocal b=2: 
alarga Y(mio,2) 


Esto no funcionará. La variable lo- 
cal b no será devuelta y, por tanto, el 
objeto azul mantendrá el mismo tama- 
ño que el rojo. Además, si utilizamos 
como parámetro un identificador junto 
con una expresión (por simple que 
sea), esto tampoco funcionará. Este se- 
rá el caso, por ejemplo. de: 


alarga Y(mio,b+1) 


Para terminar, recordad que los va- 
lores devueltos de esta manera son lo- 
cales. Ni mio ni b serán reconocidos 
desde el fichero principal. 


Conclusiones 

Todo esto puede parecer muy fioso y 
el lector puede sentir la tentación de 
evitar ciertos casos, como el uso de 
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nombres repetidos con variables loca- 
les, e incluso puede optar por utilizar 
únicamente variables globales. Pero es- 
to, a la larga, será un error. El propósito 
de las variables locales es precisamente 
el de impedir que haya demasiadas va- 
riables globales. Como éstas pueden ser 
alteradas en cualquier punto del progra- 
ma, cuando se producen errores lógicos 
debemos rastrear su valor a lo largo de 
todo el listado. Además, es más fácil 
que se produzcan errores si hay un gran 
número de variables globales, ya que 
éstas pueden interactuar entre sí. Las 
variables locales, por el contrario, actú- 
an como si estuviesen guardadas en 
compartimentos (los ficheros y las ma- 
cros), con lo cual es mucho más impro- 
bable que interactuen de manera impre- 
vista con otras variables. En general se 
considera que un listado donde predo- 
mine el uso de variables locales es mu- 
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cho más fácil de leer. Por otro lado, el 
uso de variables locales hace que sea 
más fácil adaptar ficheros o macros de 
otros autores para nuestro propio uso. 
Finalmente, las variables locales sólo 
ocupan memoria mientras se está com- 
pilando el fichero o la macro a la que 
son locales y también se dice que su uso 
es más elegante. Por todas estas razo- 
nes las variables globales sólo deben 
utilizarse cuando resulten imprescindi- 
bles, es decir, cuando se deba tratar una 
misma variable en distintos ficheros. 

En cuanto al uso de un mismo nom- 
bre para distintas variables focales, esta 
situación puede darse en ciertos casos, 
como por ejemplo cuando necesitamos 
que haya recursividad. La recursividad 
se da en «POV» cuando hacemos que 
un fichero se incluya a sí mismo o una 
macro se referencie a sí misma. El có- 
digo recursivo es más difícil de com- 
prender pero supone una simplificación 
en Ciertos casos. 

En cuanto a las macros, podemos uti- 
lizarlas para simular funciones de C de 
manera mucho más sencilla y elegante 
que el método de inclusión de ficheros. 
Podemos crear macros que devuelvan 
valores como resultado del procesa- 
miento de fórmulas complejas. Y tam- 
bién podemos definir macros que cons- 
truyan objetos de uno u otro tipo en 
función de los parámetros con que se 
les invoque. Es una pena que las nuevas 
variables locales de «POV» no sean 
idénticas a las de C y que no haya pro- 
totipos para las macros, como sucede 
con las funciones de C, pero, aun así, 
*tmacro y fflocal nos permitirán crear 
buenos “programas escénicos”. (En 
próximos números veremos ejemplos 
prácticos del uso de ambas sentencias). 


AA 


CómoO... 


Realizar animaciones 
con POV 3,1. (parte II) 


Ya hemos comentado que la aparición de nuevas sentencias de programación 
de «POV 3.1» iba a suponer una pequeña revolución para los pov-usuarios. Pues 
bien, el campo de la animación no es ninguna excepción a ésto. Así que este 
mes, además de concluir con los aspectos básicos de la animación con «POV», 
estudiaremos la forma en que estas nuevas sentencias pueden servirnos para 


crear animaciones con nuestro raytracer favorito. 
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Uns, 


e nuevo conviene 

recordar que lo que 

vamos a explicar 

aquí, aparte de los 

aspectos básicos de 

la animación (que 
siguen siendo los mismos de siempre), 
no es la forma en que se anima con 
«POV». En lugar de esto, nos centrare- 
mos en la manera en que las últimas in- 
novaciones de este programa pueden 
ayudarnos a crear animación. Por su- 
puesto, esto quiere decir que todavía no 
existen ejemplos dignos de animacio- 
nes que utilicen arrays o macros, pero, 
con un poco de paciencia, nosotros 
mismos crearemos estos ejemplos en 
los próximos meses, 


Más comandos de animación 
En el número anterior dijimos que la 
variable interna clock se incrementaba 
de manera proporcional al número de 
frames ordenados con los comandos 
+KFI y +KFE Por defecto, clock se 
inicializa con valor O y se incrementa 
hasta llegar al valor 1 en el último fra- 
me de la animación, pero esto no tiene 
por qué ser obligatorio. Así, utilizando 
el comando de línea +KlIn.n, podemos 
indicar un valor flotante n.n que será 
asignado a clock como valor inicial pa- 
ra el primer frame de la animación. Y, 
de igual forma, podemos indicar el va- 
lor final que ha de tener clock usando 
el comando de línea +KFn.n. Suponga- 
mos que invocamos a «POV» con los 
siguientes comandos de línea: 


povray Hballs.pov +oballs12a+w320 +240+KFI30+KFF60 +KI2 5 +KES 


Esta línea creará una serie de archi- 
vos TGA que irán desde balls30.tga 
hasta balls60,tga. El valor inicial del re- 
loj será de 2.5 para el primer frame a 
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Cóm0... 


Obra hecha con «POV» para el concurso 


de animaciones da Internet. 


generar y de 5 para el último. Todos los 
demás valores de clock se calcularán 
de manera que cada frame tome un va- 
lor proporcional entre 2.5 y 5. 

Ahora consideremos otra cuestión. 
Supongamos que hemos generado una 
animación de 500 frames con un valor 
de reloj que oscila entre O y 1. Hemos 
invocado a «POV» con la línea: 


povray +balls. por +oballs.tga +w320+h240 +KFII +KFFS00 


Sin embargo, después de contemplar 
los resultados, nos damos cuenta de 
que hay un fallo garrafal entre los fra- 
mes 127 y 150. ¿Tal vez un objeto se 
ha superpuesto con otro? ¿La cámara 
ha pasado a través de un modelo con 
demasiada lentitud? No importa. Lo 
que sí importa es que tendremos que 
localizar el error, corregirlo, y volver a 
renderizar los frames erróneos. Por su- 
puesto no queremos ni pensar en vol- 
ver a renderizar todos los frames de la 
secuencia. ¿Cómo solventaremos. 
pues, el problema? 

Probablemente estaréis pensando 
que basta con volver a invocar a 
«POV» con los comandos de línea 
+KF1127 +KFF150, pero esto sería un 
grave error. El problema estará en que 
haciendo esto, clock comenzará 


valiendo O para el frame 127 y acabará 
con el valor | para el frame 150, cuando, 
lógicamente, debería oscilar entre O y 1 
para los 500 frames de la secuencia. Por 
supuesto podríamos calcular el valor ini- 
cial y final que ha de tener clock para los 
frames de la lista 127-150, pero esto se- 
ría bastante fastidioso. Afortunadamen- 
te. «POV>» nos ofrece otros comandos 
que nos sacarán del aprieto. Veamos, pa- 
ra arreglar el desaguisado, podríamos in- 
vocar a «POV» con la línea: 


povray +iballs.poy +oballs.1ga +4320 1240 +KFII +KFES004+SF127+EFI50 


Con esta línea, «POV» entenderá 
que debe generar sólo el subconjunto 
de frames situado entre 127 y 150 del 
total de los 500 que forman la anima- 
ción. Además, «POV>» asignará a es- 
tos frames el valor de clock que les 
corresponde, con lo que el problema 
quedará resuelto. El comando SF in- 
dica el primer frame del subconjunto 
y EF indica el último. Lógicamente. 
no tenemos por qué recurrir a este tru- 
co sólo en caso de error. Podemos 
emplearlo para generar trozos deter- 
minados de animaciones, si sospecha- 
mos que puede haber algún problema 
con ellas o si deseamos realizar algún 
tipo de cambio. 


Dos problemas sencillos 
de animación 

A continuación estudiaremos dos ca- 
sos sencillos para comprobar cómo de- 
be emplearse clock. 

Caso 1: tenemos dos modelos que 
representan a un par de brujos que van 
a emprender un combate de hechizos. 
En la primera parte de la animación de- 
seamos que uno de ellos comience a 
crecer hasta hacerse tres veces mayor 
que su tamaño inicial. 

Podemos resolver este caso de varias 
maneras. Si el único efecto que va a te- 
ner lugar durante esta secuencia va a 
ser el agigantamiento del modelo, lo 
más sencillo es usar los comandos Kl y 
KF para poner el valor inicial del reloj 
a l y el valor final a 3. Además, tendre- 
mos que incluir esta sencilla transfor- 
mación dentro del modelo del mago: 


Objectf mago! scale<clock. clock. clock>] 


Como veis, simplemente escribimos 
clock en los parámetros de scale para 


producir un escalamiento del modelo 


en todos los ejes del mismo. Como la 
variable vale 1 en el primer frame, el 
modelo quedará con el mismo tamaño 
en la primera escena a generar, y como 
el valor final es 3, el modelo tendrá un 
tamaño tres veces mayor que el inicial 
en el último frame de la animación. 
Naturalmente, para que esto funcione 
el modelo a escalar tendrá que tener los 
pies a la altura Y=0 y estar centrado 
con respecto a los ejes X y Z. Si este 
no es el caso, el modelo aumentará de 
tamaño pero también tendrá lugar un 
desplazamiento indeseado. (Nota para 
los pov-novatos: para comprender la 
razón de esto, considerad que el valor 
dado a scale en un eje multiplica todos 
los puntos del objeto a lo largo de di- 
cho eje. Si la planta del pie está en 
Y=0, multiplicarla por 3 no tendrá nin- 
gún efecto. Si, en cambio, se halla en 
Y=2. después del escalamiento. su nue- 
va posición estará en Y=6). 
Naturalmente puede suceder que 
queramos realizar otros cambios en la 
animación, y por ello puede ocurrir que 


prefiramos dejar a clock en paz. En tal 
caso, si clock va a crecer desde O a 1, 
podemos emplear la siguiente fórmula: 


Objectfmagol scale<!+(clock*2). L+clock*2). L+(clock*2)>] 


Caso 2: queremos realizar una ani- 
mación de un sistema solar muy senci- 
llo que. aparte del sol, sólo tiene un 
único planeta al que acompaña un saté- 
lite. Queremos que el planeta gire alre- 
dedor de su eje y que complete dos re- 
voluciones en torno al sol, en una 
animación de 640 frames. 

Para preparar correctamente esta 
animación tenemos que recordar que 
en «POV» las rotaciones siempre se 
efectúan en torno a los ejes de coorde- 
nadas, los cuales se cruzan entre sí en 
las coordenadas <0,0,0>. Esto quiere 
decir que si el planeta está situado en 
<0,0,0>, entonces una rotación en el 
eje Y le hará girar sobre sí mismo en 
torno a dicho eje. Si, en cambio, el pla- 
neta está, por ejemplo, en <100,0,0>, 
entonces la misma operación de rota- 
ción le hará dar vueltas en torno al pun- 
to <0,0,0>, pero no girará sobre sí mis- 
mo. (Nota: pedimos disculpas por 
explicar algo tan básico, pero si alguien 
no entiende esto le resultará complica- 
do preparar animaciones con «POV». 
Si este es vuestro caso, será mejor que 
comencéis por leer el número 16 de 
Rendermanía). En la Figura 1 tenemos 
un ejemplo de cómo podríamos crear 
el sistema solar deseado. 

El caso del planeta es muy sencillo. 
Se supone que éste —al igual que el sa- 
télite— ha sido creado centrado en torno 
a los ejes de coordenadas. Por eso la 
primera operación que efectuaremos 
sobre él será la que le hará describir ro- 
taciones en torno a su eje, Para ello he- 
mos usado el valor 3600 para la rota- 
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ción en Y, lo que significa que el plane- 
ta completará diez rotaciones en torno 
a su eje a lo largo de toda la animación. 
El siguiente paso es hacerle rotar en 
torno al sol, al que suponemos en 
<0,0.0>, y para ello simplemente tras- 
ladaremos al planeta a la distancia ade- 
cuada del sol (en el plano X-Z) antes 
de ordenar la siguiente rotación. Esta 
operación utiliza el valor 720, lo que 
significa que el cuerpo habrá completa- 
do dos revoluciones en torno al sol al 
llegar al fin de la animación. 

En cuanto al satélite, su caso es algo 
distinto, Este cuerpo no gira en torno a 
sí mismo pero sí lo hace con respecto al 
planeta. Hemos definido arbitrariamen- 
te que la distancia entre ambos cuerpos 
es de 15 unidades. Por tanto. si el saté- 
lite ha sido creado centrado en <0,0,0>, 
nuestra primera tarea será colocarlo a 
15 unidades del centro de coordenadas, 
a fin de poder preparar su rotación en 
torno al planeta. Esto se hace en la ope- 
ración siguiente, en la que se ha em- 
pleado el valor 1800 para que el satéli- 
te complete cinco revoluciones en torno 


CómoO... 
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juguete es obra de Nazrat Durand. 


al planeta. Después aplicamos al satélite 
la misma traslación que al planeta y lue- 
go la misma rotación (para que siga a és- 
te en su órbita en torno al sol). 

Sin embargo. las distancias y las di- 
mensiones utilizadas no tienen nada 
que ver con las que cabría esperar de 
los verdaderos cuerpos celestes. Más 
aún, las órbitas descritas son círculos 
perfectos en lugar de elipses, pero lo 
importante era exponer un caso de ro- 
tación tan simple como fuese posible. 


Un aviso sobre las texturas 
Existen algunas sentencias como jit- 
ter y crand que añaden a las texturas 


efectos que dependen de valores alea- 


torios, Estas sentencias pueden conse- 
guir buenos resultados cuando lo úni- 
co que queremos es crear una escena 
estática. Sin embargo, su uso debe evi- 
tarse a toda costa cuando se pretende 
crear una animación. Por ejemplo, en 
el caso de crand, esta sentencia intenta 
reproducir un efecto rugoso y granula- 
do trabajando de manera aleatoria en 
los píxeles de la textura. Como dicho 
efecto es totalmente aleatorio (y traba- 
jado pixel a pixel), el siguiente frame 
puede producir un efecto indeseado de 
ruido, ya que el “granulado” consegui- 
do en la textura no tiene por qué ser 
igual en dos frames seguidos. (Nota: 
este problema también puede presen- 
tarse con cualquier programa que per- 
mita utilizar texturas procedurales y 
disponga de sentencias similares. Cree- 
mos que hace algún tiempo llegó a 
nuestras manos una animación de un 
lector hecha con «Imagine»— y que te- 
nía precisamente este problema). 


El problema 
de las trayectorias 

Antes de «POV 3.0» no existía nin- 
guna forma —dentro del mismo fichero 
escénico— de decirle a «POV» que 
cambiase una acción por otra depen- 
diendo del valor de clock. Está claro 


Figura 1: trozo de código para generar el caso del planeta y su satélite. 


object[ planeta rotale yF3600*clock translate<100,0,0> rotate y*720] 
object[ satelite translate<15,0.0> rotate y*1800 transtate<100.0,0> rotate y*720) 


que ahora, gracias a Hif, esto sí es posi- 
ble. Ahora podemos tener un cuerpo 
moviéndose en una dirección durante 
un tiempo y ordenarle en un momento 
dado que se pare o que cambie de sen- 
tido o que haga cualquier otra cosa. Na- 
turalmente, tswitch también puede 
ayudarnos en estos casos y tenemos un 
sencillo ejemplo de su uso en la anima- 
ción boing, donde switch es utilizada 
para decidir qué fórmula debe aplicarse 
al movimiento de una pelota. 

Sin embargo, con o sin sentencias de 
programación, aún tenemos que en- 
frentarnos a problemas bastante fasti- 
diosos. Hasta ahora todos los casos que 
hemos expuesto han sido ejemplos de 
movimientos muy sencillos. Por su- 
puesto podemos utilizar fórmulas más 
complejas para crear animaciones de 
cosas tales como caídas de cuerpos, re- 
botes de bolas de billar, etc. Asimismo 
también es muy fácil hacer matertali- 
zaciones de objetos, alteraciones de es- 
cala, cambios de textura, movimientos 
de agua, etc. Pero todo esto no resuelve 
un problema típico con el que el usua- 
rio siempre debe enfrentarse: ¿cómo 
podemos definir una trayectoria com- 
pleja. llena de giros y cambios de senti- 
do, para un cuerpo cualquiera? 

Ea solución obvia es emplear la sen- 
tencia array. (Esta nueva característica 
de «POV» ya fue explicada en el nú- 
mero anterior, aunque los ejemplos de 
uso que se dieron eran casi todos de co- 
locación de objetos. Ahora, en cambio, 
veremos cómo sacar partido a los 
arrays en el terreno de la animación). 
Una primera posibilidad es crear un 
array de una sola dimensión y guardar 


en él una serie de registros de movi- 
miento para un cuerpo. Cada registro 
de este tipo podría estar organizado de 
la siguiente manera; 

e campo 0: Vacío inicialmente. 

e campo 1: Un valor en flotante que 
indica la posición X del próximo punto 
al que debe ir el cuerpo. 

e campo 2: Idem para el eje Y 

e campo 3: Idem para el eje Z. 

El array guardaría, pues. las posicio- 
nes espaciales por donde habría de pa- 
sar el cuerpo. lo que definiría su trayec- 
toria. Ahora bien, ¿cómo nos las 
arreglaríamos para preparar la anima- 
ción a partir de estos datos? Una posi- 
ble solución podría pasar por hacer que 
el valor inicial de clock fuese igual a 1 
y el valor final igual al número total de 
frames que queremos generar. Luego 
podríamos calcular la distancia total 
que ha de recorrer el cuerpo y dividirla 
entre el valor de clock para hallar la 
distancia que recorre el cuerpo para ca- 
da frame de animación. (Nota: estamos 
asumiendo que el cuerpo mantiene una 
velocidad constante durante toda la ani- 
mación). Hecho esto no nos sería difícil 
calcular el valor de clock en que ha de 
terminar cada registro-desplazamiento 
(calculando la distancia entre la posi- 
ción actual del cuerpo y la final indica- 
da en el registro). Anotaríamos enton- 
ces el valor final de clock para cada 


registro de desplazamiento y luego. una 
vez ya en el bucle de animación. com- 
pararíamos el valor actual de clock con 
el almacenado en el registro en curso 
para determinar si continuamos tratan- 
do dicho registro o pasamos al si- 
guiente. Para calcular el movimiento 
efectuaríamos incrementos en los ejes 
X. Y y Z. Incrementos que previamen- 
te habríamos calculado para cada re- 
gistro al hallar la ecuación de la recta 
entre la posición final del registro an- 
terior y la posición final del registro 
actual (o, en el caso del registro inicial, 
al hacer los cálculos entre la posición 
inicial del cuerpo y la final del primer 
registro). En cuanto al cálculo de la 
distancia entre puntos, emplearíamos 
la fórmula de la Figura 2. 

(Nota: para no repetir los mismos 
cálculos iniciales en cada frame ten- 
dríamos que incluir a éstos en una com- 
paración del tipo +tif (clock=1)...). Por 
supuesto podríamos hacer que el array 
incluyese las trayectorias de movi- 
miento de más cuerpos o bien utilizar 
más de un array para esto, Por tanto, lo 
único que tendríamos que hacer para 
crear una nueva animación sería poner 
clock con el valor total del número de 
frames deseados y escribir las posicio- 
nes 3D para las trayectorias. 

Pero este método tampoco es perfec- 
to y tiene dos problemas: el primero es 
que obliga a todos los cuerpos a mante- 
ner una velocidad constante y el segun- 
do que las trayectorias de movimiento 


Figura 2: Fórmula para hallar la distancia entre dos puntos. 


Si tenemos dos puntos <x0, yO, zl)> y <xl, yl, z1>. podemos definir la distancia entre los mismos 


con la formula: 


DISTANCIA | (x, 17 + (Y, Yo +12) 20) 
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son siempre líneas rectas. Lo ideal se- 
ría poder definir cambios de velocidad 
y tener un procedimiento que interpre- 
tase los puntos 3D del array como pun- 
tos de una trayectoria spline, con lo que 
los movimientos estarían definidos por 
curvas suaves en lugar de por rectas. 
Aquí lo mejor sería crear una macro 
que pudiese ser utilizada por cualquier 
usuario, aunque éste no tuviese conoci- 
mientos matemáticos. De esta manera 
cualquiera podría definir trayectorias 
complejas para sus modelos fácilmen- 
te, aunque no supiese lo que es una cur- 
va spline. (Nota: nosotros somos un 
ejemplo perfecto de ignorancia e inep- 
titud en el campo de las mates, pero 
aun así, como la creación de una ma- 
cro de este tipo nos parece un asunto 
de importancia capital, creemos que re- 
pasaremos algo sobre este tema), 

Otro problema de gran importancia 
es el de la definición de movimientos 
para objetos antropomórficos. Sería 
ideal poder definir una matriz de movi- 
mientos para andar, correr, etc., y po- 
der aplicarle leves variaciones aleato- 
rias dentro de una animación. Si esto 
se logra, el crear una animación de un 
gran ejército en movimiento sería algo 
al alcance de la mano. 


Una idea para 
un compilador de acciones 
Otra idea que podría tener interés se- 
ría el de utilizar un array para guardar 
órdenes para los elementos que inter- 
vienen en las animaciones. De este mo- 
do, si ya hemos creado el código para 
cumplir esas órdenes, lo único que ten- 
dremos que hacer para preparar una 
animación cualquiera será preparar los 
modelos y cambiar los valores guarda- 
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CómoO... 


John Aughey ha creado esta 
de los juguetes de Rubik. 


dos en el array. Estos valores podrían 
formar registros similares al ya expli- 
cado antes, pero con la diferencia de 
que podría incluirse un campo de or- 
den que indicase para qué son los res- 
tantes parámetros del registro. Así 
podrían definirse órdenes para la cá- 
mara, para las transformaciones en las 
texturas de los objetos, para sus des- 
plazamientos, etc. De esta manera 
bastaría con escribir los valores del 
array para preparar una animación 
compleja, sin que tuviéramos que pre- 
ocuparnos por escribir ningún código 
adicional. (Nota: la creación de un sis- 
tema como este implica bastantes que- 
braderos de cabeza, pero intentaremos 
crear un ejemplo de esto en un plazo 
tan corto como sea posible). 


Ideas para animaciones 

Suponiendo que las ideas aquí ex- 
puestas no acaben resultando imprac- 
ticables, ¿qué tipo de proyectos podrí- 
amos afrontar? Vamos a anotar las dos 
primeras ideas que han acudido a 
nuestra cabeza: 

e Una partida de ajedrez. Podríamos 
utilizar un array para guardar registros 


con órdenes de desplazamiento para las 
piezas, con lo que podríamos crear nue- 
vas animaciones (de otras partidas) 
muy fácilmente, con sólo cambiar la 
partida “escrita” en el array. Además, 
podríamos crear código para que cada 
pieza se “comiese” a las demás de una 
manera distinta (como en Killer Chess 
y otros programas parecidos). 

e ¡Una batalla de tanques en una ciu- 
dad! De nuevo podríamos utilizar los 
arrays para guardar valores de trayecto- 
rias a fin de definir las evoluciones de los 
carros de combate. Si creamos los edifi- 
cios de la ciudad desde un modelador 
gráfico sería sencillo tomar nota de las 
posiciones 3D que nos interesasen, a fin 
de definir las evoluciones de los tanques. 

La animación de un ejército medie- 
val es algo en lo que por el momento 
será mejor no pensar. También podría 
ser muy interesante el escribir un pro- 
grama de verdad, con comportamien- 
tos para los personajes, de manera que 
ellos mismos pudiesen definir sus pro- 
pios movimientos. A partir de «POV 
3.1», esto es ya teóricamente posible, 
aunque de momento será mejor pensar 
en cosas mas sencillas. 
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Nota importante. Podéis remitirnos vuestros trabajos o consultas, bien por carta a la dirección que 
figura en el sumario de Pcmanía, o vía e-mail a rendermania.pcmania O hobbypress.es 


Animaciones a lo grande 


Continuamos publicando animaciones de gran extensión (Pa rte II) 
remitidas por los lectores. Queremos recalcar que el foro 
de este mes es una excepción a la regla del tamaño, algo que sólo ha sido 


posible por circunstancias especiales. Así, aprovechamos para advertiros 


que no enviéis trabajos superiores a los 5 Megas comprimidos. 


Victor Barbera Romero 1.998 


Pr 


Nuestro amigo Victor Barbero Romero nos ha enviado unas especta- 
culares escenas renderizadas con «POV 3.0» de un magnífico piano mode- 
lado con «Spatch» y de un encuentro donde un caballero pilotando un caza 
da Una paliza a dos pobres orcos. Bien por tí, pero parece un poco fuera de 
lugar que suministres un caza para el bando humano en un mundo de clara 
ambientación y tecnología medievales. En cuanto a tus cartas, parece que 
tienes una pequeña confusión con las medidas de nuestros modelos. En las 
escenas los orcos y caballeros tienen una altura aproximada de entre 160 a 
190 unidades porque en ellas 100 unidades equivalen a un metro. 

Aunque no te lo creas, la versión de «POV» de Windows no es más rá- 
pida que la de MS-DOS (bueno, en un render de una hora y viendo la ima- 
gen mientras se lanza, la versión de Windows puede ser unos segundos más 


lenta). Lo que sucede es que sí requiere más memoria (por algo funciona ba- 


Jo Windows). Esto puede hacer que, si tienes poca memoria, el programa tenga que hacer muchos 
más accesos a disco duro de los que precisaría bajo MS-DOS, con lo cual el render sí será mucho más 


lento. Por otro lado, si estás renderizando y pones 


Vistos Barker Homero. (93% 


la ventana de «POV>» para Windows en un segun- 
do plano, el programa también irá más lento . Y 


para terminar, ¿qué prioridad has puesto para la 


velocidad del render? (Mírate la opción “Render render priority” y ponla a hightest). 
En cuanto a tu último coemntario de tu carta tenemos que decir que sentimos lo de tu 
versión de «Rhino». La verdad es que salió una nueva beta de libre uso después de la 
tuya. pero PCmanía decidió no publicarla porque sólo iba a tener un par de meses de 
vigencia. Estaremos atentos a este asunto por si aparecen nuevas versiones. 

Gracias por tus ánimos y toma nota de nuestras felicitaciones por tu habilidad con 
«POV» y «Spatch» (y sobre todo por el piano y sus texturas). 
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Mn É os 


A pesar de creer 
que hemos visto 
antes la metralle- 


ta medieval (cre- 


ada con el pro- 


grama «POV») 


de Kepa Diez 


Ara, no estamos 


seguros de haber- 


la publicado, así que incluimos aquí estas escenas (¿las mismas?) enviadas con tu 


nueva carta, Tu metralleta será utilizada en la próxima batalla (¿quizá contra las ham- 


brientas evormigas?). Y aquí va la contestación a algunas de tus preguntas: 


Con respecto a «Imagine», no conocemos otro “traductor” de modelos aparte de 
3dto3d y 3Dwin. 


POr tora parte, solemos dejar sin tocar el assumed_gamma que viene por defecto. 


Preferimos trastear con la intensidad y colocación de las luces. En cuanto a tu quinta 


pregunta, emplearíamos «Spatch» y «POV» o «Rhino» y «POV» o cualquier otro 


modelador con «POV». 


Gracias por tu metralleta y en- 


horabuena por tu horrorosa 


transformación (seguimos es- 


perando ese mech hecho con 


el programa «Imagine»). 


Roberto Ajenjo Murcia es otro povmaníaco recién enganchado que 
nos envía este mes sus primeras obras. ¿Una crítica? Bueno, tus escenas 
son prometedoras pero aún tienes que practicar bastante con el modelado y 
la creación de texturas. En cuanto a tus preguntas, algunas de ellas ya han 
sido contestadas en los últimos números, y respecto a las demás: 

3) ¿Números atrasados de Rendermanía sin comprar PCmanía? Nos te- 
memos que esto no está previsto. 

4) Llama a la redacción y pide que comprueben el estado de tu pedido. 
5) Lo de los plug-ins de «MAX» tiene bastante miga y además, por aho- 
ra, no podemos hablar de ello aquí. 


dado bastante con nuestro raytracer favorito. 
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6) Sobre «POV>», aquí sólo se ha publicado el “Raytracing Il” de Anaya, pero este libro es- 
tá ya bastante desfasado, pues trata la versión 2.2 de «POV» (cuando el programa ya va por 
la 3.1). De todas formas, para cuando leas esto, los últimos números deberían haberte ayu- 


Antonio Delgado Castillo es otra 
nueva víctima del virus infográfico y 


pide algunos consejos sobre cómo 


empezar con «MAX». Bien, lo que 


sigue no te va a parecer demasiado 
original pero lo que necesitas es prac- 
ticar. practicar y (además) practicar. 
Para empezar no intentes realizar pro- 
yectos demasiado complejos. Co- 
mienza intentando hacer modelos 
sencillos, como piezas de ajedrez y 
objetos por el estilo, y de momento 
olvídate de cosas como el modelado 
orgánico. No podemos enviarte ma- 
nuales y, en cuanto a libros. quizá el 
mejor sea el de Roberto Potenciano. 
De todos modos no te limites a seguir 
mecánicamente los ejercicios descri- 
tos en los libros e idea tus propios 
proyectos (al tiempo que estudias có- 
mo llevarlos a cabo). Los comienzos 
pueden ser duros, pero si te aplicas 
acabarás disfrutando a lo grande. 


Aunque últimamente es fre- Quienes recuerden la ex- 


cuente recibir e-mails de Argenti- celente animación que publi- 
na no lo es tanto el recibir cartas camos de este autor en el nú- 
de ese país por vía postal. Este ha mero 7 de Rendermanía, 


sido el caso de la misiva de Jesús sabrán que Luis Cárdenas 


Nicolás Martín Colom, en la que 


Salido es un infografista con 
este autor nos envía unas —real- un gran interés en los efectos. 


mente- fantásticas imágenes crea- Así, en las dos nuevas anima- 


das con «POV», «Imagine» y ciones que Luis nos ha remi- 


«3D Studio». Entre ellas hay un par de magníficos mechs. un increíble helicóptero y un jeep. Con to- tido veremos efectos de llu- 
do hay que decir que en algunas imágenes, como en imagine-7 o imagíne-9, parecen retocadas a ma- via, viento, de luz y de 
no y a veces se hace difícil apreciar debidamente el modelo. En cuanto a tus preguntas: partículas. También hay al- 
1) Como sabes, para simular una reflexión sobre un objeto desde «3D Studio», se indica el nombre gún que otro morphing, re- 
de una textura en el indicador reflection del cuadro del Materials Editor, pero creemos que no te re- lámpagos. y otras cosas. 
fieres a esto, sino a las llamadas reflexiones automáticas. Para conseguirlas debes pulsar sobre el Amigo Luis, sentimos haber 
recuadro de “A”. en el recuadro map de reflection. (No somos unos expertos en «3D Studio» pero tardado tanto tiempu en pu- 


creemos que se trata de estu). 


blicarte esto. pero es que no 


2) No acabamos de entender lo que dices del “cono de luz” en la armóstera. «3D Studio» no puede nos es fácil publicar trabajos 


producir directamente estos efectos, aunque quizá sea posible simularlos aplicando una textura proce- de tanta extensión. Enhora- 
dural con transparencia parcial sobre un objeto buena por tus efectos. 
en forma de cono. 

3) Creemos que los Ipas que generan luces tlare 
en «3D Studio» funcionan como lo hacen los 
flares de «Polyray», «POV» y otros programas. 
Colocan una textura sobre un objeto bidimen- 
sional. Suponemos que podrías hacer lo mismo 


manualmente, creando una textura adecuada. 


Fernando Herrera Rodríguez (Mixerable Productions) nos envía una animación taurina que 
ha dado algunos problemas (hemos tenido que ver los flis uno a uno). Como Fernando nos pide 
una crítica, aquí la añadimos, a pesar de que él mismo se hace una propia. Para empezar la ani- 
mación de los personajes es demasiado rígida y la propia animación del toro no se corresponde 
con la que debería tener este animal, recordando por el contrario a la de un insecto. Además, los 
vuelos de cámara son excesivamente rápidos e impiden captar los detalles de las películas. En fin, 
te ha fallado un poco la planificación del trabajo. Y de tus preguntas... 

1D) Eos objetos construidos desde «POV» no tienen malla así que no pueden ser exportados tá- 


cilmente a «3D Studio». Que sepamos nadie ha hecho ninguna herramienta capaz de hacer esto. 


2) Uno de los mejores sitios para encontrar buenos modelos de libre uso es 3Dcate en www. 3dcafe.com. 
3) «MAX» tiene una opción para exportar sus objetos a «3D Studio», aunque se pierde calidad debido al problema de la exportación de texturas. 
4) No podemos publicar librerías completas de modelos sin el consentimiento de los autores de las mismas. 


5) Pasamos tus cuestiones sobre Pixel a Pixel a los responsables del concurso. 
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pa 


Los hermanos 

y 

nos envían esta anima- 
ción que publicamos a 
pesar de que sólo en 
parte está compuesta 
por imagen sintética. Anotaros un tirón de orejas por 
no incluir ninguna carta para el foro del lector con los 


detalles de vuestro trabajo. 


vn Y 


7 


nos en- 
vía una animación realizada con «MAX» 
sobre el grupo Los Suaves. La animación 
incluye música del grupo e imágenes es- 
caneadas 
de las por- 
tadas de 
sus discos 
además de 
algunas 
notas rela- 


cionadas 


- - 


con dicho 
grupo. Gracias por lu felicitación. espera- 


mos tus próximos trabajos. 
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Otra carta res- 
catada del olvido 


es la de 


que nus envió esta 


misiva a finales del 
año pasado. En ella Carlos pone nuevas texturas al antiguo lancero de 
Rendermanía y adjunta algunas escenas creadas con «POV». En 
cuanto a las preguntas de tu carta (la escrita a mano), preferimos que 
enviéis las escenas en formato JPG ya que es quizá el que más com- 
prime sin apenas pérdida de calidad. Y sobre los modeladores, bien. 
si todavía continuas leyendo este suplemento ya habrás leído sobre 
programas co- 
mo «Spatch» y. 
«Rhinoceros» 
y es probable 
que dentro de 
poco presente- 
mos otros nue- 
vos. Perdona 


por el retraso. 


el 
famoso autor de las aventuras 
virtuales de Piolín (y Mazinger). 
vuelve de nuevo a estas paginas 
con una animación de... ¡54 Me- 
gas comprimidas! Este tamaño 
ya de por sí hubiera hecho muy 
difícil su publicación, pero es 
que. además. en el momento de 
escribir estas líneas no disponía- 
mos de ninguna unidad ZIP, por lo que nos ha sido imposible ver tu trabajo. 
Con todo, como ya te conocemos, estamos seguro de que valdrá la pena publi- 
carte. así que hemos pasado tu ZIP a los responsables de la maquetación que sí 
poseen esta unidad de ZIP). Así 
que tendremos que esperar a que 
aparezca el número correspon- 
diente para ver tu animación, co- 
mo todos los demás. Mientras 
tanto remitimos a los lectores a tu 


carta en el foro. 


